home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 26 / Cream of the Crop 26.iso / bbs / thstafx1.zip / TERHOST.ZIP / BULLE007.TXT < prev    next >
Text File  |  1996-10-13  |  12KB  |  224 lines
  1.        The following text was written by Scott Dudley, author of
  2.        MAXIMUS, one of the most common BBS systems in use on the planet.
  3.  
  4.        Scott has also written a mail processor called SQUISH which is
  5.        also a world leader in processing Fidonet mail.  The following
  6.        was taken from the documentation file for Squish with the kind
  7.        permision of Mr. Dudley.
  8.  
  9.  
  10.                                  NETWORK PRIMER
  11.                                 by, Scott Dudley
  12.                                    1:249/106
  13.  
  14.        This section is intended as a primer for SysOps who are new to
  15.        FidoNet or a FidoNet Technology Network (FTN).  This section
  16.        covers many of the terms and concepts which are required for
  17.        everyday FidoNet operations.
  18.  
  19.  
  20.                                   The Basics
  21.  
  22.        The term "FidoNet" refers to an amateur electronic mail network,
  23.        run collectively by a group of system operators.  In the
  24.        beginning, FidoNet started out as a simple system for exchanging
  25.        private messages between different bulletin boards.  Since then,
  26.        FidoNet has grown into a full-fledged electronic mail and
  27.        conferencing network which has members in most countries of the
  28.        world.
  29.  
  30.        FidoNet itself is organized into a numerical hierarchy of
  31.        "zones", "regions", "nets", "nodes" and "points".  Each member of
  32.        FidoNet, individually known as a "node", can be uniquely
  33.        identified by that system's zone, net, node and point numbers.
  34.        To define each term:
  35.  
  36.        Zones are wide geographical areas, usually covering one or more
  37.        continents.  At the time of writing, FidoNet currently has six
  38.        zones:  zone 1 (North America), zone 2 (Europe), zone 3
  39.        (Oceania), zone 4 (South America), zone 5 (Africa) and zone 6
  40.        (Asia).
  41.  
  42.        Nets cover a much smaller area than zones; a net usually
  43.        encompasses a large city and the surrounding area.  There are
  44.        usually many nets within each zone, each of which represents a
  45.        small geographical area within that zone.
  46.  
  47.        Nodes are individual systems.  Most nodes consist of bulletin
  48.        board systems, although a few nodes are devoted exclusively to
  49.        handling mail.  If you wish to become a member of FidoNet and you
  50.        are running a BBS, this is probably where you will start.
  51.  
  52.        Points are users on an individual system.  Normally, points do
  53.        not run full-time systems, since they simply send and receive
  54.  
  55.        mail through their "bossnodes" (the nodes where the points pick
  56.        up their mail).  As the size of the network grows, points are
  57.        becoming increasingly popular.  If you don't wish to run a full-
  58.        time system, this is probably where you'll start.
  59.  
  60.        These four terms can be combined to give a "network address"
  61.        which identifies any one node in the network.  The format of a
  62.        FidoNet address is as follows:
  63.  
  64.                              zone:net/node[.point]
  65.  
  66.        For example, given a user in zone 1, in net 249, with a node
  67.        number of 106, and a point number of 2, that user's full address
  68.        would be '1:249/106.2'.  The point number is optional, so both
  69.        1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2.
  70.  
  71.        This mode of addressing is sometimes referred to as "4D" or four-
  72.        dimensional, since it includes the four basic elements of a
  73.        network address.
  74.  
  75.  
  76.                                The Outside World
  77.  
  78.        Like other electronic mail systems, it's possible to enter a
  79.        private message on a FidoNet system and have that message be
  80.        delivered to its final destination in a short period of time.
  81.        FidoNet systems "talk" with each other over telephone lines,
  82.        using one or more sophisticated handshaking protocols.  To get a
  83.        message (known in this context as "NetMail") from point "A" to
  84.        point "B", the following sequence of events has to occur:
  85.  
  86.        *    The message is created.  Most Fido-compatible software
  87.        packages can be used to generate a private message to a user on
  88.        another node.  The destination address is entered, using the
  89.        standard 4D addressing scheme.
  90.  
  91.        *    The on-disk message is then converted to packet (or *.PKT)
  92.        form.  If you are running BinkleyTerm, this will be performed by
  93.        Squish after a user logs off.  If you are running FrontDoor or a
  94.        similar mailer type, this will be performed by the mailer itself
  95.        on startup, or while your mailer is connected to other systems.
  96.  
  97.        There are four reasons for converting a message into a packet:
  98.  
  99.        1)   The packet structure is much more flexible than the local
  100.        message structure.  All of the fields (such as the To:, From: and
  101.        Subject: fields) in a packet are variable length, whereas the
  102.        fields in stored messages are fixed-length.
  103.  
  104.        2)   Packets are the "compatibility layer".  Since all systems
  105.        convert messages to the *.PKT format before sending them to
  106.        another system, there are few compatibility problems.  This means
  107.        that systems can store their local message bases in different
  108.        formats, but still be able to exchange messages easily.  In
  109.        addition, more than one message can be stored in a single packet.
  110.        Sometimes hundreds (or even thousands) of messages can be stored
  111.        in a single packet.
  112.  
  113.  
  114.        3)   Messages in a packet can have a different address from the
  115.        packet itself.  The packet itself has a destination (the system
  116.        where you'll be sending that packet directly to), but each
  117.        message has an individual destination address.  This is useful,
  118.        for example, when a long-distance call is required to connect
  119.        with certain parts of the network.  The message's final
  120.        destination always stays the same, but by sending the packet to
  121.        someone who is local to you (and then having that someone send it
  122.        to another local system, and so on), costs can be controlled
  123.        quite effectively.  Since the interim destination of packet
  124.        doesn't need to be the same as the final destination of the
  125.        message, routing of messages via the lowest-cost route can be
  126.        performed.
  127.  
  128.        4)   Packets can be given a "flavour".  A "flavour" (or a
  129.        behaviour characteristic) helps your system decide what to do
  130.        with an individual message.  For example, the "hold" flavour
  131.        instructs your system to hold the message and wait for the
  132.        destination system to call and pick it up.  Other flavours
  133.        include "crash" (send a message directly to the destination),
  134.        "direct" (same as crash), and "normal" (wait for later routing
  135.        commands).
  136.  
  137.        Packets always have an extension of *.PKT.  (Qualifier:  if you
  138.        are running a BinkleyTerm system, they may have an extension of
  139.        *.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley
  140.        always changes them to *.PKT files before they are sent to
  141.        another system.)
  142.  
  143.        *    After the packet is created, it can be optionally archived
  144.        using a file compression utility.  Compression is useful when
  145.        transferring large volumes of mail or sending to long- distance
  146.        sites, since compressing mail saves both time and money.
  147.  
  148.        *    The system which created the message then tries to call the
  149.        destination system.  Obviously, if both systems are fairly busy,
  150.        this may take a while.  Messages are sent back and forth between
  151.        systems through the use of mailers, also known as "front ends".
  152.        Mailers call out to deliver waiting mail, handle incoming
  153.        messages and files, and in general, supervise the entire file
  154.        transfer.
  155.  
  156.        *    After the two mailers connect (using one of several FidoNet
  157.        protocols), waiting mail and files are transferred between the
  158.        two systems.
  159.  
  160.        *    After the transfer completes, the receiving system then
  161.        tries to import the message.  If the packet was compressed by the
  162.        sender, it will be decompressed.  The *.PKT files will then be
  163.        imported (otherwise known as "tossed") into the local message
  164.        base, ready for the recipient to read.
  165.  
  166.        Although transferring NetMail can involve much more than just
  167.        what is given above, this should give you a grasp on NetMail
  168.        fundamentals.
  169.  
  170.  
  171.                            Is There an Echo In Here?
  172.  
  173.        In the beginning, FidoNet consisted solely of nodes exchanging
  174.        NetMail.  The only way to get a message from "here" to "there"
  175.        was to send a private NetMail message.  However, a technology
  176.        called "EchoMail" was developed in late 1985; EchoMail is
  177.        analogous to a public message area or conference, but EchoMail
  178.        areas (sometimes known as "echoes") are shared among several
  179.        other systems.
  180.  
  181.        EchoMail is organized into different groups of echoes, each with
  182.        a different topic.  For example, the topics of FidoNet echoes
  183.        range from Maximus Support to deep-sea fishing and many more
  184.        special-interest groups.  To facilitate topic-oriented EchoMail,
  185.        each echo must given a tag (or area name).  This tag is used to
  186.        uniquely identify that EchoMail area when transferring messages
  187.        with other systems.  (It doesn't matter what you call the echo on
  188.        YOUR system, as long as you are using the same tag as everyone
  189.        else.)  Area tags are one word only, although they can include
  190.        periods and underscores.  To start receiving an echo area, you
  191.        need to know the tag of that area.  For example, the area tag for
  192.        the echo dealing with hardware and other technical issues is
  193.        "TECH".
  194.  
  195.        EchoMail messages are normally public, and they are entered in a
  196.        message area just like a normal message.  EchoMail messages also
  197.        look like normal, locally-entered messages, but with some special
  198.        control information at the bottom of each message.
  199.  
  200.        After an EchoMail message is saved, an EchoMail utility (such as
  201.        Squish) is invoked to "scan" that message out to the rest of the
  202.        network.  Unlike NetMail, EchoMail areas have an electronic
  203.        topology.  Some echoes are very large, and as such, the cost to
  204.        directly send a message to each system which carried that echo
  205.        would be prohibitive.  Instead, each system carrying that echo
  206.        only transfers EchoMail messages to neighbouring systems.  (The
  207.        neighbour you receive an echo from is also known as your "feed".)
  208.        EchoMail messages get sent from the originating system to its
  209.        neighbours, and from those systems to their neighbours, and so
  210.        on.  Despite this "hoppity-hop" method of transferring messages,
  211.        EchoMail is fairly quick; it can often take less than three days
  212.        for a message to travel from the USA to Australia and back.
  213.  
  214.        Just like NetMail, echoes are sent to other systems in packets.
  215.        EchoMail messages are almost always compressed, since most of the
  216.        popular echoes have a daily throughput anywhere from 20 to 200
  217.        messages per day.
  218.  
  219.             Copyright 1991 by Scott J. Dudley.  All rights reserved.
  220.                              Used with permission.
  221.  
  222.                                      * * *
  223.  
  224.